It is not uncommon for logic designs to have multiple timing domains. The multiple timing domains may come from a multiplicity of clocks, or from constraints such as skew constraints, recovery/removal constraints on asynchronous clear/load signals, and IO timing constraints. Long-path and short-path timing constraints may also operate to increase the number of timing domains in a logic design.
Optimization procedures utilized by logic design tools may require that design solutions be summarized with respect to timing. Such procedures may compute a single scalar number to score the “quality” of the design solution. A scalar timing quality metric allows two design solutions to be evaluated with respect to each other by simply comparing their corresponding metric values.
In the past, worst slack was the parameter used by electronic design automation (EDA) tools to compute a single scalar timing quality metric. When a logic design had multiple timing domains, a worst case slack was computed for each domain. The smallest of the timing domain slacks was used as the quality metric value of the design solution. This approach has several drawbacks. Since the quality of a design solution is determined entirely by the performance of the worst domain, this approach was unable to appreciate solutions where the worst domains are equal but where other domains have more preferable solutions. This approach would also prefer solutions that had marginally better worst slack at the cost of significant degradation of other timing domains.
Thus, what is needed is an improved method and apparatus for calculating a scalar quality metric for quantifying the quality of a design solution.